London A-Z road map
In my first story ‘User Experience is …’ I promised that …
"over the course of a few stories, I’ll try and cover a few of the sciences we draw upon in our art as a creative community to create engaging experiences."
We’re all product people, we work in and around products in order to deliver the best experience or service possible. I’ve worked for a long time with Product Managers to share and articulate what problem we are solving and what value we are adding. This often results in the need for a roadmap. But this is where things can go wrong.
London A-Z road map
A product roadmap is a high-level visual summary that maps out the vision and direction of your product. A product roadmap communicates the why and what behind what you’re building. A roadmap is a guiding strategic document as well as a plan for executing the strategy.
Most importantly many of these definitions does not mention when or any units of time, just the what and why.
A roadmap is exactly what it says it is. It’s all about joining up the dots and realising how the pieces connect together. It’s not about putting unknown or made up timelines against unknown or misunderstood features.
A product roadmap should not be a gant chart of arrows showing features. It should not follow a timeline format. In fact there shouldn’t really be any mention of time on it.
If you look at these ‘timeline roadmaps’, it’s basically just a chart, with:
The problem is, the further out that timeline stretches, the more unknown things become and so the more you’re making things up.
A timeline roadmap, by its very format, means that you are giving a due date and duration to every thing you’re putting on it. That’s a whole lot of assumptions you’re making.
A timeline roadmap is just a big pile of assumptions of things that aren’t yet known, understood and that nothing is going to change. They’re also assuming that everything works straight away, things start straight after the previous one finishes, you know how long each feature is going to take and that each feature on the roadmap is the right thing to build. And they are all dangerous assumptions, given the fact things do change.
After reading around the topic of product roadmaps and stitching together the best frameworks, ideas and approaches from leading lights like Janna Bastow, Jared Spool and John Cutler, here’s the best of the bunch put together for a killer product roadmap for all stakeholders.
Product vision template, ProdPad
Janna Bastow, Co-Founder of Prodpad recommends a product vision to be the cornerstone of your product roadmap. So this can be used to have conversations around with stakeholders to inform your roadmap, this then filters down to inform your daily decisions as a product team. But it can’t be too lofty or intangible that it’s ultimately meaningless.
There are a surprising number of moving parts to an effective product vision. A good product vision captures who the customer is, who the user is, and the value proposition and clearly links back to company objectives. In other words, it’s clear, specific and doesn’t lend itself to multiple interpretations.
Janna Bastow, Prodpad
MOST Framework showing how missions, objectives, strategies and tactics play a part and come together
Adviso recommend, before a company launches a product, the first step is to define a strategic plan. Again this acts as a reference point to guide conversations and decisions moving forward.
However these concepts can be mixed up. A strategic plan is sometimes confused with a list of goals, but should be a reflection on what success means for the organisation, and how they plan to optimise for that success. Also, if each one isn’t clear and concrete, the ideas can be difficult for internal teams to understand and use.
To create a MOST (Mission, Objective, Strategies and Tactics) framework you need to understand the company’s mission at the top level. And know where you’re able to define objectives, strategies and tactics. Knowing this you’re able to influence objectives, increase your impact on the mission and be a more successful product person.
Measuring the impact of initiatives
Product objectives are the outcomes that show you’re delivering against the product strategy. In order to achieve an objective, you might change the product or experience, these are your initiatives. You can use this to build the story behind your product to communicate it’s vision and the progress you’re making.
You might not always know if initiatives will help achieve the objective, so it’s better to frame them as problem statements. The steps to take complete the initiative become the experiment. The experiments will aim to test your hypotheses, so that certain changes to the product or experience will solve customer problems. This will provide the impact on signals or metrics for success. Which will indicate progress towards your objective and release some business benefit.
As experiments are run and feedback gathered, it’s metrics will be impacted. Understanding how the product’s pulse or metrics change, allows you to adjust the roadmap to better achieve the objectives and sense check them and the overall strategy to see if it’s still working.
A lean roadmap acts as a prototype for the product strategy. Constantly being tested, reviewed and feedback added to it, so that it evolves and stays current and effective.
Janna Bastow, Co-Founder of Prodpad recommends combining the vision, product objectives, and ‘time horizons’ to articulate your product strategy. Ditch the timeline roadmap and embrace the lean product roadmap!
I realise the timeline formats are still popular (from doing a google image search), but moving away from these old school timeline format of roadmaps, helps you avoid a whole heap of assumptions, unknowns and inaccuracies.
The timeline roadmap, it’s basically a chart with time on the x-axis, creating a timeline, not a roadmap. Plotting things to do, is simple at first, but the further out you get out, the more unknowns you’re dealing with, so the more assumptions you’re making and ultimately making things up. So the further you go out should represent a change in understanding, visibility and flexibility.
A timeline roadmap, because it features a period of time, means you’re inadvertently giving a duration and due date for everything on that timeline roadmap. So that’s whole lot of assumptions that are being made like:
At the end of the day, the value in the roadmap isn’t the artefact you produce, it’s the discovery process you take as things get closer to the present.
Looking back at the stories I’ve previously written has allowed me to see what ground I’ve covered, but also realise what ground is left to cover, and what I haven’t mentioned. So next up I’m going to look at how the whole team should be taken on a voyage of discovery, as it will need all the talents of the team to best navigate through the uncertainty in User experience is … a partnership in learning.
Originally written as part of the ‘User Experience is …’ series for UX Collective.